☰ Navigate this post:
Introduction
I happened upon and was impressed by Adrian Roselli’s post, “Dialog Focus in Screen Readers”. His testing set me a line of thought current to my consistent theme of questioning why we make our screen readers’ experience so difficult by design?
Adrian includes links to four posts on the topic by by Scott O’Hara from 2016 to 2019. The dates catch my attention. Are we discussing an acceptable web design pattern, or proliferating the ableism of yore? I replied to Adrian’s post with the following comment and set forward some thinking. I commented my understanding.
Here’s me banging my drum. Perhaps approaching the dialog as an ableist idiom can encourage us to stop only converting its visually biased design patterns into a secondary audible experience? Instead, design an inclusive inline ‘hide, include, and show’ pattern that works and convert that to our visual users’ dialog paradigm styled with CSS?
For example, we seem to have inline accordions and tab patterns’ focus mostly working inclusively? Visually style the resulting panel absolutely on the top layer and inject the non-semantic translucent background division tag you labelled Overlay as needed?
Your demonstration loads the dialog content outside the main element, which is perhaps the root cause for the focus send and retrieve complication? The overlay strategy is a visual one to prevent visual users accidentally interacting with the content behind it. That’s actually not a problem for screen reader users or keyboard navigators when we capture their moving away from the dialog content to a new focus? Or, do we focus-trap them and force the close action? One is a solution.
I am of course paying little attention to WAI-ARIA Authoring Practices 1.1, August 2019, Section 6.4 Deciding When to Make Selection Automatically Follow Focus because I don’t fully understand it. I’m a designer and not a developer so you may need to beat me over my head with a metaphorical conductor’s baton of grounding facts? I liked Sections 6.1 and 6.5.
Among other references, my thinking seems to follow WAI ARIA Practices Alert example, where content is dynamically loaded into the inline div container on clicking the button and Alert Dialog Example. Both load content adjacent to, and inline with the trigger button.
What I am certain of is that accessible is not inherently inclusive. We make people using screen readers work hard enough already. Our industry is managed by visual bias justifying a beautiful visible user experience for majority market; passing off hi-fi wireframes with no thought to the semantic of (DOM or A11y Tree) content. Although engineering is being driven by legislation toward accessibility, perhaps leading inclusive content design at source can remove the habitual barriers our graphic-first legacy encourage?
Or maybe my drumming is out of time with the orchestra? Only, as a newbie I like the tune…
Note to grammarists: Yes, proper English demands dialog written as, “dialogue”. However, “dialog” is a noun and soon a tag <dialog>.
My Initial Thinking
Reading Adrian’s and Scott’s posts I can understand that there must be a driving engineering reason for architecting these dialogs in the way they are. And in turn, why the dialog element is being promoted. Both reasons elude me.
Adrian’s CodePen dialog demonstration is used to test a variety of screen reader and operating systems I have no access to. And I am grateful to read his findings. In it, the dialog is characteristically included in the DOM outside of the main content and away from the actuated button interaction. Why?
<body> <header><!--content--></header> <main> <!--useful content and interaction that calls the dialog--> </main> <div><!-- DIALOG CONTAINER (and background) --></div> <footer><!--content--></footer> </body>
I feel the answer is ableist visual design and engineering. When we approach the problem from an inclusive content-first perspective, we are only:
- Hiding or omitting content by default.
- Loading omitted content on demand.
- Presenting the content.
- Offering a means to escape or remove (close) the content and progress.
These intentions can be accomplished using already well supported inclusive design patterns, can’t they?
Consider expand and collapse or tabs and panels. They:
- Offer a transaction to access desired content.
- Enable the selection, availability, and and actioning of that content.
- Offer a means to close, remove, or at the least navigate from that content.
That’s a modal dialog right there?
There Must be Solutions, Surely?
As I commented on Adrian’s post, the dialog pattern under discussion seems to have evolved from an ableist pattern or expectation: from a time before screen reader users’ experience was considered. Here, WCAG seems intent on bolting in accessibility after the fact and again offers techniques to convert visual design into accessible content. That isn’t the same as presenting inclusive content.
Simple Analysis
I am convinced we can use more inclusive design patterns. First, let’s disassemble the dialog:
- We call the dialog.
- Where dynamic, we call the content into the dialog.
- We introduce a visual and mouse-proof barrier to prevent visual-led mouse interaction with the user interface behind the dialog and capture focus.
- The dialog is consumed and a means of escape offered. A Close button or navigation away.
Comparison with acceptable patterns
We can compare that list to the previous list for expand and collapse or tabs and panels. The difference is the barrier to interaction visually behind the dialog.
Well, whoopie-do. We can replicate that barrier and it’s visual layer depth with CSS and possibly a light JavaScript function, of course. The dialog doesn’t need to be outside the main content or anything other than inline?
Initial Summary of Thinking
Logically:
- A transaction that is vital to our users’ progress should always be available to the DOM.
- It is only hidden at run-time with CSS
{display:none}, or JavaScript’shide(). - It is available with JavaScript and CSS switched off.
- It is positioned proximal and semantically to the control in the DOM where it is expected to be.
Dynamically called and loaded dialog content or components:
- Require JavaScript, of course.
- Don’t need CSS when the dialog is proximal to its initiating action.
With CSS switched off, orchestrating any dialog content to enter the DOM at the “bottom of the page” makes no semantic or cognitive sense, with or without scrolling to the new focus using accessibility adjuncts?
So why slave to doing exactly that?
Or am I only being naive?
It’s an Existing Pattern?
Go to WAI ARIA Practices Alert Dialog Example for a demonstration of this approach. And let’s rethink inclusive versus accessible, I thought.
<body> <header><!--content--></header> <main> <!--useful content and interaction that calls the dialog--> <div><!-- DIALOG CONTAINER (and background) --></div> <!--more useful content and interaction--> </main> <footer><!--content--></footer> </body>
Adrian Replies
Adrian kindly replied to my comment. At first, my confidence in anything accessibility was a little rocked. Perhaps it still is?
I recall in week 2 of the Masters UX Design program and a fellow student claiming accessibility is too expensive, resource hungary, and difficult. I retorted that it is a moral right and not so difficult when we design for it from the off. I still hold to that and the problems accessibility workers face seem to only escalate. More on that later.
Pat, I would be willing to see a prototype or design of your ideas. To comment on your notes in the hopes it can guide you…
“Instead, design an inclusive inline ‘hide, include, and show’ pattern that works and convert that to our visual users’ dialog paradigm; styled with CSS?”
We know a simple disclosure is not a fit, especially after seeing the problems screen reader users had with GitHub’s attempt at using <details> / <summary> as a dialog.
“For example, we seem to have inline accordions and tab patterns’ focus mostly working inclusively?”
Testing I have performed with dozens of users suggests that we do not. Some users prefer how focus jumps into a panel while others do not. The same is true for moving focus between tabs themselves. As a result, I often urge clients to avoid these patterns if they cannot test with their own users.
“Your demonstration loads the dialog content outside the main element, which is perhaps the root cause for the focus send and retrieve complication?”
It loads at the end of the DOM so it is less likely to be encountered by accident (through scripting errors or otherwise). Loading it at the end also makes it easier to disable the rest of the page via inert.
“The overlay strategy is a visual one to prevent visual users accidentally interacting with the content behind it.”
The overlay is there as a visual cue, yes, but also takes a click event so the dialog can be dismissed when a user clicks outside it. Otherwise it is not exposed to screen reader users.
“That’s actually not a problem for screen reader users or keyboard navigators when we capture their moving away from the dialog content to a new focus? Or, do we focus-trap them and force the close action? One is a solution.”
Screen reader users can navigate by more than Tab, so we need to make the underlying page as a whole inert to prevent them jumping to a heading or control or block of text in the wrong context (outside the dialog).
“Among other references, my thinking seems to follow WAI ARIA Practices Alert example, where content is dynamically loaded into the inline div container on clicking the button and Alert Dialog Example. Both load content adjacent to, and inline with the trigger button.”
The ARIA Authoring Practices example of inline alerts is one alternative to dialogs, and is common for displaying groups of error messages above a form.
The alert dialog example is not adjacent to the Discard button in the DOM; it is adjacent to the button’s parent. Regardless, since the page is made inactive the button would lose focus (and the user their place in the pace) unless the developer sets focus on or within the dialog that appears. This is expected.
I want to caution that the ARIA Authoring Practices have issues related to little testing, poor mobile support, lacking touch support, and seek to re-create the Windows95 interface on the web (among other issues). I say this to caution you that while a handy reference for idealized patterns, few actually work with users.
The Missing Je Ne Sais Pas!
There’s this moment in a 2012 Google developer’s video presented by the capable Racheal Shearer: watch her eyes and subconscious drop in demeanor when she demonstrates the gadget. The idea is to make a previously inaccessible Google button and dialog a triumph of ARIA. Alas, the moment is broken. Even the camera angle changes swiftly and far from covering her discomfort, it amplifies it.
She knows something isn’t right and can’t vocalise it because it totally destroys the whole aim of the video; 40-minutes into an otherwise confident and useful presentation. It’s devastating.
No one noticed, right? Sure, I cannot be the only one in 8 years? The incident builds quickly from 39 minutes and 30 seconds:
- Focus lands on widget. ChromeVox announces, “Navigation, Add to circles button”.
- Rachel presses Enter. Focus moves to the first of four checkboxes. ChromeVox announces, “Entering dialog.”
- Rachel says, “This is great. You can see that focus moved to that checkbox…you can move around with Tab to the other checkboxes.”
- Rachel presses the Tab key. ChromeVox announces, “Zero family. Checkbox not checked.”
On entering the dialog, the focus is already on the first check box combination and it isn’t announced. Rachel tabs forward and to her relief, the second checkbox combo is announced. She moves swiftly on and regains her composure. She summarises with, “…this is great! You can see that focus moved to that dialog and ChromeVox said, ‘entering dialog’…for someone who cannot see a screen, this interaction is perfect…“
In fact, this only highlights the points Adrian is making in his original post, and that we’ve just waited for 40 minutes to watch how technically brilliant Google was in 2012. Sorry Rachel, it happens to all of us.
More Thinking Required
I am reminded of my former surgical colleagues’ quip, “the deeper you stick your finger, the dirtier it gets”. I cleaned that up a touch. Also the motto, “do no harm”. I try to follow their diagnostic principles of treating root causes and not symptoms, too.
Given our moral duty to enable inclusive design and my excess of zeal to implement it from source, I am too often discouraged or stripped of confidence to profess any strategy to teams. The spiralling awareness of how disorganised the world of accessible is, is suffocating at times and that’s 30 years after first summarising any design as, “it depends”.
The root cause is the ableist advantages of design, engineering habit, and belief coupled with institutionalised priority to visual design in user experience thinking. With that thinking, why are we presenting a Boolean on and off dialog at all? Often it contains a decision with context to previous content. Why do we restrict or seek to control our users’ movement within it? Why must the background page be inert?
Of course I can recognise when existing content strategies may require that and what is it that creates that requirement? The first is a timeout message on a platform:
- We cannot know where in the presented content our user is.
- We cannot inject the message at that mystical point anyway without alerting that the message is there.
- The dialog content isn’t directly related to the page content or context.
Naivety
So, of course there is a requirement for the dialog pattern; to play with focus and to notify each combination of browser, screen reader, and preference. I was naive to think we can work in a space without visual design (CSS) and to rely only on the semantic, text, and context of content in every circumstance.
Resolution and moving forward
Naivety of all circumstance aside, when we design a dialog to capture a data decision, we should still question its requirement. A navigation or list filter is not a dialog, for example. It’s a navigation or button made available to all.
Use Cases?
In the following 2019 video, favourite accessibility whiz, Rob Dodson of A11ycasts runs through his take on the dialog. In it he confirms:
- There are dialog use cases.
- Dialog content should be truly hidden and not only displaced off the viewport.
- To leave focus available on the browser address bar to enable keyboard navigators to avoid malicious activity when trapped within the dialog.
Useful. I like that the short dialog content is announced. I do not like all the mentions of polyfils. That’s crazy talk given the investment in developing what can quickly become an outdated legacy component.
What isn’t useful is his bolting on his example dialog to an interaction that is clearly not a use case for a dialog. An Add To Basket button click does not need a confirmation? The Checkout button is the confirmation or opportunity to undo the action. And that set me thinking again. What are the use cases where we cannot design out a dialog?
Here’s the video, which is set to start at 5 minutes and 10 seconds when Rob makes his point about hiding rather than displacing dialog content.
So, what are the use cases where we must hide the dialog and its modal controls? That’s a great question and I will return to it. My intention is to investigate which can be designed out, and which cannot. Your comments will be useful.
In the meantime, Adrian Negger’s Modalz Modalz Modalz discovered via Scott O’Hara’s posts does a good job summarizing and building on my thoughts for alternative methods. For example, he asks, “have you considered the following?
- Non-modal dialogs
- Inline content
- Expanding elements
- A new page
- An Undo pattern (think Rob Dodson’s poor user case of a But Now button going to a Basket page)
Adrian Neggers’s Do’s and Don’ts.
Do:
- Make the dialog easy to close
- Give it a single purpose
- Keep it short
- Think accessible, accessible, accessible
Don’t:
- Modal inception: don’t open a modal from a modal.
- Present modals full-screen. That’s a new page.
- Present multi-step modals. (Some full page “modal” styles do this healthily and page to page).
- Self-spawn modals.
- Marketing modals. (Spotify! Looking at you, chum!)
Solutions that Fail?
In his YouTube video that follows, Zoltan Hawryluk uses an image for the HTML5 dialog Close button. This offers the opportunity to introduce the dialog’s context using the image alternative text. The dialog tag’s aria-labelledby and aria-describedby lead the dialog’s semantic content to be announced, too.
Referring back to Adrian’s testing across screen readers, operating systems, and browser combinations I’d like to see how this fares. One observation I can make, and perhaps celebrate as a learning outcome from this post, is that the focus is fully trapped within the dialog. Our user cannot access the browser chrome or address bar. I know now that is bad.
It looks good and then there are references to a polyfill and I turn off. I guess the ‘polyfil’ is just a Javascript plug-in: homemade or a download? I’m not convinced we must rely on a function to progress all semantic tasks? And Adrian’s testing echos around my skull. It’s not the full answer.
Summary
As Adrian, Adrian, Rachel, and Rob remind us, screen reader users may navigate by any means and preference by focus or heading and visual users by their navigation tool of choice. So the core questions on when to deploy this troublesome dialog must be:
- Is it needed? Can we install the content inline with our users’ experience?
- Is the message or decision content in time with the experience of the page content?
- Do we need to prohibit access to the page content from the decision we are promoting? For example if required for review?
As with so many topics I choose to explore, it depends. Of course. And here’s the rub, in traditional user testing we are encouraged to find 80+ percent of usability problems by testing 5 people (a lore that is always misquoted). With accessibility, the range of Alternative Browser Technologies and user abilities seems to throw that metric out the window? We cannot possibly “test our users” of a banking or educational platform. Everybody needs access!
With Adrian Roselli’s observations on the corruption of the guidelines and techniques legislation are professing we follow through with WAI, we must make more noise. Of course I am frustrated! I want to do the best for all of our users inclusively and at most every turn I find with accessibility, “it depends” actually translates to, “so what?”
For the most part, accessibility is trailed behind visual design. We paint a pretty interface and then give hope everyone might access it regardless of the additional effort and degraded experience that offers. Perhaps banging my drum to equalise that status-quo is a place to start? And then I see people like Adrian and Scott banging the same drum for years and there’s essentially no great change.
There again, you gotta be in it to win it. Crack on.
Reference this post
Godfrey, P. (Year, Month Day). Title. Retrieved , from,